As traffic in communication networks continually increases, improving the efficiency with which radio resources are used within a communication network is an important ongoing challenge. Radio Friendly Pacing is one method for improving efficiency of resource usage, according to which TCP traffic from the communication network to client devices is sent in short bursts, as opposed to in a continuous stream. Continuous transmission not only occupies radio frequency resources but also requires the client device to continually use its radio transceiver resources for reception of the stream, leading to increased battery usage. Radio Friendly Pacing thus not only allows for more efficient use of radio resources but also saves battery on the receiving client devices. In some examples of Radio Friendly Pacing, the procedure may be implemented in a proxy which is located in the operator network and forwards network originating traffic to client devices via the appropriate radio resources. FIGS. 1 and 2 illustrate examples of proxy location within a communication network. The proxy 2 may be a transparent proxy, receiving all TCP packets for transmission from the network to the client devices 4 and also all TCP packets for transmission from the client devices 4 to the network. The proxy may for example communicate with a gateway 6, which may be in communication with a Radio Access Network (RAN) 8 via which the client devices 4 connect to the communication network. When implementing Radio Friendly Pacing, the proxy 2 receives traffic from the network in a standard fashion. The proxy then implements Radio Friendly Pacing by forwarding the received traffic in small bursts on the Downlink towards the destination client devices.
Many applications designed to run on client devices use heartbeat messages in the Uplink in order to ping their respective server, check the network connection or to poll for more data. This frequent low bandwidth traffic uses a significant amount of radio resources, and so reduces the capacity of each cell within the RAN as well as reducing the bandwidth available to other client devices in the cell. This “background” TCP traffic is typically sent by applications which are not active on the client device but merely running in the background. Such traffic may also be sent when the client device is idle but the application is still running. As the client device is the transmitting party for this background traffic, the traffic causes particularly high levels of battery usage, as well as generating a high load on the radio network, with many small pings requiring frequent state changes in the network, and so requiring a lot of signaling, placing a high load on the radio network.